activating xml2enc makes client getting HTML-Page take very long

--00151750e950afbee70478007df4
Content-Type: text/plain; charset=ISO-8859-1

Alright, xml2enc works, does not crash, and correctly translates UTF8 back
to ISO-8859-1 after it was converted to UTF-8 by mod_proxy_html.

However, activating that translation back to ISO-8859-1 makes the whole
process take up a lot of time, and I have no idea why, so I am asking for
ideas.
First, how slow is slow? Time from pushing the send button until the new
webpage is loaded rises from 10.6 to 103 seconds.
And every page of the webapplication I have tried is just as slow, so its
not just a particular page which loads very slowly.

Top on the server shows that the server is sitting idle, so it's not that
the recoding is taking up that much CPU (which would be ridiculous anyway).

Configuration which is slow (in /etc/apache2/apache2.conf):
ProxyHTMLEnable On
ProxyHTMLCharsetOut *
ProxyHTMLExtended On
ProxyHTMLMeta On
ProxyHTMLLogVerbose On

It becomes fast if I comment out the line "ProxyHTMLCharsetOut *"
SSL has been disabled to reduce the complexity of the problem.

==Snippets from /var/log/apache2/error.log (Loglevel debug)==
[Mon Nov 09 11:38:14 2009] [debug] mod_proxy_http.c(60): proxy: HTTP:
canonicalising URL
//localhost:50100/dwhfe/pub/Authentication.htm;jsessionid=26 BB5D99A6206A68651C07DFCDD291B1
....
[Mon Nov 09 11:38:16 2009] [debug] mod_proxy_http.c(1803): proxy: end body
send
[Mon Nov 09 11:38:16 2009] [debug] proxy_util.c(2008): proxy: HTTP: has
released connection for (localhost)
[Mon Nov 09 11:38:31 2009] [debug] mod_proxy_http.c(60): proxy: HTTP:
canonicalising URL //localhost:50100/dwhfe/app/style/ajax/theme/ui.base.css
....
[Mon Nov 09 11:38:31 2009] [debug] mod_proxy_http.c(1803): proxy: end body
send
[Mon Nov 09 11:38:31 2009] [debug] proxy_util.c(2008): proxy: HTTP: has
released connection for (localhost)
[Mon Nov 09 11:38:46 2009] [debug] mod_proxy_http.c(60): proxy: HTTP:
canonicalising URL //localhost:50100/dwhfe/pub/Authentication.htm
....
[Mon Nov 09 11:38:46 2009] [debug] mod_proxy_http.c(1803): proxy: end body
send
[Mon Nov 09 11:38:46 2009] [debug] proxy_util.c(2008): proxy: HTTP: has
released connection for (localhost)
[Mon Nov 09 11:39:01 2009] [debug] mod_proxy_http.c(60): proxy: HTTP:
canonicalising URL //localhost:50100/dwhfe/pub/Authentication.htm
....
[Mon Nov 09 11:39:01 2009] [debug] mod_proxy_http.c(1803): proxy: end body
send
[Mon Nov 09 11:39:01 2009] [debug] proxy_util.c(2008): proxy: HTTP: has
released connection for (localhost)
[Mon Nov 09 11:39:16 2009] [debug] mod_proxy_http.c(60): proxy: HTTP:
canonicalising URL //localhost:50100/dwhfe/pub/Authentication.htm
....
[Mon Nov 09 11:39:16 2009] [debug] mod_proxy_http.c(1803): proxy: end body
send
[Mon Nov 09 11:39:16 2009] [debug] proxy_util.c(2008): proxy: HTTP: has
released connection for (localhost)
[Mon Nov 09 11:39:31 2009] [debug] mod_proxy_http.c(60): proxy: HTTP:
canonicalising URL //localhost:50100/dwhfe/pub/Authentication.htm
....
[Mon Nov 09 11:39:31 2009] [debug] mod_proxy_http.c(1803): proxy: end body
send
[Mon Nov 09 11:39:31 2009] [debug] proxy_util.c(2008): proxy: HTTP: has
released connection for (localhost)
[Mon Nov 09 11:39:46 2009] [debug] mod_proxy_http.c(60): proxy: HTTP:
canonicalising URL //localhost:50100/dwhfe/pub/Authentication.htm
....
[Mon Nov 09 11:39:46 2009] [debug] mod_proxy_http.c(1803): proxy: end body
send
[Mon Nov 09 11:39:46 2009] [debug] proxy_util.c(2008): proxy: HTTP: has
released connection for (localhost)

As can be seen, in each case the connection is released, and then there is
no more work for 15 seconds. So the time is not lost while the module is
translating (e.g. because of a timeout).

==Packet traffic sniffed in front of the proxy (client is 192.168.0.9,
outgoing port is 443 (no SSL), and between proxy and backend (port serving
the data internally is 50100)==
( I=traffic between proxy and backend; E=traffic between proxy and client )
I 16:25:42.693049 IP 127.0.0.1.50100 > 127.0.0.1.41421: P 9513:14946(5433)
ack 2117 win 297 #HTML Data
I 16:25:42.693125 IP 127.0.0.1.41421 > 127.0.0.1.50100: . ack 14946 win 387
E 16:25:42.694255 IP 192.168.0.100.443 > 192.168.0.9.55306: .
9473:13853(4380) ack 1895 win 82 #HTML Data Part 1
E 16:25:42.694412 IP 192.168.0.100.443 > 192.168.0.9.55306: P
13853:14924(1071) ack 1895 win 82 #HTML Data Part 2
E 16:25:42.694860 IP 192.168.0.9.55306 > 192.168.0.100.443: . ack 12393 win
16425
E 16:25:42.695077 IP 192.168.0.9.55306 > 192.168.0.100.443: . ack 14924 win
16425
E 16:25:57.702107 IP 192.168.0.100.443 > 192.168.0.9.55306: F 14924:14924(0)
ack 1895 win 82
E 16:25:57.702514 IP 192.168.0.9.55306 > 192.168.0.100.443: . ack 14925 win
16425
E 16:25:57.702715 IP 192.168.0.9.55306 > 192.168.0.100.443: F 1895:1895(0)
ack 14925 win 16425
E 16:25:57.702736 IP 192.168.0.100.443 > 192.168.0.9.55306: . ack 1896 win
82
E 16:25:59.105400 IP 192.168.0.9.55308 > 192.168.0.100.443: S
1692924107:1692924107(0) win 8192
E 16:25:59.105543 IP 192.168.0.100.443 > 192.168.0.9.55308: S
3020885945:3020885945(0) ack 1692924108 win 5840 1460,nop,nop,sackOK,nop,wscale 7>
E 16:25:59.105832 IP 192.168.0.9.55308 > 192.168.0.100.443: . ack 1 win
16425
E 16:25:59.106002 IP 192.168.0.9.55308 > 192.168.0.100.443: P 1:523(522) ack
1 win 16425 # GET Request
I 16:25:59.106895 IP 127.0.0.1.41852 > 127.0.0.1.50100: F
1298653661:1298653661(0) ack 1288489298 win 900
I 16:25:59.106932 IP 127.0.0.1.50100 > 127.0.0.1.41852: R
1288489298:1288489298(0) win 0
I 16:25:59.107142 IP 127.0.0.1.41424 > 127.0.0.1.50100: S
3012199744:3012199744(0) win 32792
I 16:25:59.107217 IP 127.0.0.1.50100 > 127.0.0.1.41424: S
3023186444:3023186444(0) ack 3012199745 win 32792 16396,nop,nop,sackOK,nop,wscale 7>
I 16:25:59.107245 IP 127.0.0.1.41424 > 127.0.0.1.50100: . ack 1 win 257
I 16:25:59.107985 IP 127.0.0.1.41424 > 127.0.0.1.50100: P 1:597(596) ack 1
win 257 # the GET Request

I'm not sure if I am interpreting all of this correctly, but to me it seems
obvious, that nobody is talking to the backend: The proxy is sending back
its acknowledgment that it got the data at 16:25:42.693125. The next time
anyone talks to the backend at all is at 16:25:59.106895, at which point the
TCP connection is reestablished.
There seems to be a problem between client and proxy making them reestablish
their TCP connection at 16:25:59.105400.
Seeing how regularly spaced the delays are, I am going to assume that the
TCP connection is lost and reestablished after each send file.
But what does ANY of this have to do with whether or not I enable xml2enc in
the reverse proxy!?

Does anyone have any reasoning that can make a bit of sense out of this. I
simply fail to see the logic here...

Thanks in advance!

--00151750e950afbee70478007df4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Alright, xml2enc works, does not crash, and correctly translates UTF8 back =
to ISO-8859-1 after it was converted to UTF-8 by mod_proxy_html.

How=
ever, activating that translation back to ISO-8859-1 makes the whole proces=
s take up a lot of time, and I have no idea why, so I am asking for ideas.<=
br>
First, how slow is slow? Time from pushing the send button until the new we=
bpage is loaded rises from 10.6 to 103 seconds.
And every page of the we=
bapplication I have tried is just as slow, so its not just a particular pag=
e which loads very slowly.


Top on the server shows that the server is sitting idle, so it's no=
t that the recoding is taking up that much CPU (which would be ridiculous a=
nyway).

Configuration which is slow (in /etc/apache2/apache2.conf):<=
br>
ProxyHTMLEnable On
ProxyHTMLCharsetOut *
ProxyHTMLExtended On
Prox=
yHTMLMeta On
ProxyHTMLLogVerbose On

It becomes fast if I comment =
out the line "ProxyHTMLCharsetOut *"
SSL has been disabled to =
reduce the complexity of the problem.


==Snippets from /var/log/apache2/error.log (Loglevel debug)== r>[Mon Nov 09 11:38:14 2009] [debug] mod_proxy_http.c(60): proxy: HTTP: can=
onicalising URL //localhost:50100/dwhfe/pub/Authentication.htm;jsessionid=
=3D26BB5D99A6206A68651C07DFCDD291B1

....
[Mon Nov 09 11:38:16 2009] [debug] mod_proxy_http.c(1803): proxy: en=
d body send
[Mon Nov 09 11:38:16 2009] [debug] proxy_util.c(2008): proxy=
: HTTP: has released connection for (localhost)
[Mon Nov 09 11:38:31 200=
9] [debug] mod_proxy_http.c(60): proxy: HTTP: canonicalising URL //localhos=
t:50100/dwhfe/app/style/ajax/theme/ui.base.css

....
[Mon Nov 09 11:38:31 2009] [debug] mod_proxy_http.c(1803): proxy: en=
d body send
[Mon Nov 09 11:38:31 2009] [debug] proxy_util.c(2008): proxy=
: HTTP: has released connection for (localhost)
[Mon Nov 09 11:38:46 200=
9] [debug] mod_proxy_http.c(60): proxy: HTTP: canonicalising URL //localhos=
t:50100/dwhfe/pub/Authentication.htm

....
[Mon Nov 09 11:38:46 2009] [debug] mod_proxy_http.c(1803): proxy: en=
d body send
[Mon Nov 09 11:38:46 2009] [debug] proxy_util.c(2008): proxy=
: HTTP: has released connection for (localhost)
[Mon Nov 09 11:39:01 200=
9] [debug] mod_proxy_http.c(60): proxy: HTTP: canonicalising URL //localhos=
t:50100/dwhfe/pub/Authentication.htm

....
[Mon Nov 09 11:39:01 2009] [debug] mod_proxy_http.c(1803): proxy: en=
d body send
[Mon Nov 09 11:39:01 2009] [debug] proxy_util.c(2008): proxy=
: HTTP: has released connection for (localhost)
[Mon Nov 09 11:39:16 200=
9] [debug] mod_proxy_http.c(60): proxy: HTTP: canonicalising URL //localhos=
t:50100/dwhfe/pub/Authentication.htm

....
[Mon Nov 09 11:39:16 2009] [debug] mod_proxy_http.c(1803): proxy: en=
d body send
[Mon Nov 09 11:39:16 2009] [debug] proxy_util.c(2008): proxy=
: HTTP: has released connection for (localhost)
[Mon Nov 09 11:39:31 200=
9] [debug] mod_proxy_http.c(60): proxy: HTTP: canonicalising URL //localhos=
t:50100/dwhfe/pub/Authentication.htm

....
[Mon Nov 09 11:39:31 2009] [debug] mod_proxy_http.c(1803): proxy: en=
d body send
[Mon Nov 09 11:39:31 2009] [debug] proxy_util.c(2008): proxy=
: HTTP: has released connection for (localhost)
[Mon Nov 09 11:39:46 200=
9] [debug] mod_proxy_http.c(60): proxy: HTTP: canonicalising URL //localhos=
t:50100/dwhfe/pub/Authentication.htm

....
[Mon Nov 09 11:39:46 2009] [debug] mod_proxy_http.c(1803): proxy: en=
d body send
[Mon Nov 09 11:39:46 2009] [debug] proxy_util.c(2008): proxy=
: HTTP: has released connection for (localhost)

As can be seen, in e=
ach case the connection is released, and then there is no more work for 15 =
seconds. So the time is not lost while the module is translating (e.g. beca=
use of a timeout).


==Packet traffic sniffed in front of the proxy (client is 192.168.0=
..9, outgoing port is 443 (no SSL), and between proxy and backend (port serv=
ing the data internally is 50100)==
( I=3Dtraffic between proxy and =
backend; E=3Dtraffic between proxy and client )

I 16:25:42.693049 IP 127.0.0.1.50100 > 127.0.0.1.41421: P 9513:14946(543=
3) ack 2117 win 297 #HTML Data
I 16:25:42.693125 IP 127.0.0.1.41421 >=
127.0.0.1.50100: . ack 14946 win 387
E 16:25:42.694255 IP 192.168.0.100=
..443 > 192.168.0.9.55306: . 9473:13853(4380) ack 1895 win 82 #HTML Data =
Part 1

E 16:25:42.694412 IP 192.168.0.100.443 > 192.168.0.9.55306: P 13853:1492=
4(1071) ack 1895 win 82 #HTML Data Part 2
E 16:25:42.694860 IP 192.168.0=
..9.55306 > 192.168.0.100.443: . ack 12393 win 16425
E 16:25:42.695077=
IP 192.168.0.9.55306 > 192.168.0.100.443: . ack 14924 win 16425

E 16:25:57.702107 IP 192.168.0.100.443 > 192.168.0.9.55306: F 14924:1492=
4(0) ack 1895 win 82
E 16:25:57.702514 IP 192.168.0.9.55306 > 192.168=
..0.100.443: . ack 14925 win 16425
E 16:25:57.702715 IP 192.168.0.9.55306=
> 192.168.0.100.443: F 1895:1895(0) ack 14925 win 16425

E 16:25:57.702736 IP 192.168.0.100.443 > 192.168.0.9.55306: . ack 1896 w=
in 82
E 16:25:59.105400 IP 192.168.0.9.55308 > 192.168.0.100.443: S 1=
692924107:1692924107(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK&g=
t;

E 16:25:59.105543 IP 192.168.0.100.443 > 192.168.0.9.55308: S 3020885945=
:3020885945(0) ack 1692924108 win 5840 <mss 1460,nop,nop,sackOK,nop,wsca=
le 7>
E 16:25:59.105832 IP 192.168.0.9.55308 > 192.168.0.100.443: =
.. ack 1 win 16425

E 16:25:59.106002 IP 192.168.0.9.55308 > 192.168.0.100.443: P 1:523(522)=
ack 1 win 16425 # GET Request
I 16:25:59.106895 IP 127.0.0.1.41852 >=
127.0.0.1.50100: F 1298653661:1298653661(0) ack 1288489298 win 900

I 16:25:59.106932 IP 127.0.0.1.50100 > 127.0.0.1.41852: R 1288489298:128=
8489298(0) win 0
I 16:25:59.107142 IP 127.0.0.1.41424 > 127.0.0.1.501=
00: S 3012199744:3012199744(0) win 32792 <mss 16396,nop,nop,sackOK,nop,w=
scale 7>

I 16:25:59.107217 IP 127.0.0.1.50100 > 127.0.0.1.41424: S 3023186444:302=
3186444(0) ack 3012199745 win 32792 <mss 16396,nop,nop,sackOK,nop,wscale=
7>
I 16:25:59.107245 IP 127.0.0.1.41424 > 127.0.0.1.50100: . ack =
1 win 257

I 16:25:59.107985 IP 127.0.0.1.41424 > 127.0.0.1.50100: P 1:597(596) ack=
1 win 257 # the GET Request

I'm not sure if I am interpreting a=
ll of this correctly, but to me it seems obvious, that nobody is talking to=
the backend: The proxy is sending back its acknowledgment that it got the =
data at 16:25:42.693125. The next time anyone talks to the backend at all i=
s at 16:25:59.106895, at which point the TCP connection is reestablished. r>
There seems to be a problem between client and proxy making them reestablis=
h their TCP connection at 16:25:59.105400.
Seeing how regularly spaced t=
he delays are, I am going to assume that the TCP connection is lost and ree=
stablished after each send file.

But what does ANY of this have to do with whether or not I enable xml2enc i=
n the reverse proxy!?

Does anyone have any reasoning that can make a=
bit of sense out of this. I simply fail to see the logic here...


Thanks in advance!




--00151750e950afbee70478007df4--

Re: activating xml2enc makes client getting HTML-Pagetake very long

On 10 Nov 2009, at 08:56, Martin Gerdes wrote:

> First, how slow is slow? Time from pushing the send button until the
> new webpage is loaded rises from 10.6 to 103 seconds.

10.6 is already horrendously slow (unless perhaps it's a 20-year-old
PC),
which leads me to wonder what you're doing. One thing is that with
ProxyHTMLExtended On you could be parsing lots of text, so make
sure you use flags to ensure you don't apply more rules to it than
you absolutely need to.

> And every page of the webapplication I have tried is just as slow,
> so its not just a particular page which loads very slowly.

The encoding to utf-8 happens within libxml2 if the input encoding is
supported. The output is a invokes apr_xlate, which in turn is normally
a wrapper for iconv. So this could be pointing the finger at your
iconv.

Does it make any difference if lots of small rewrites have happened
vs. if nothing matched any proxy_html rules?

> Top on the server shows that the server is sitting idle, so it's not
> that the recoding is taking up that much CPU (which would be
> ridiculous anyway).

Does it make any difference if you send an HTTP/1.0 request
or force a connection close? Can you get mod_diagnostics
output to track the data running through the filter?

--
Nick Kew

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: activating xml2enc makes client getting HTML-Page

--000325557352ac1b7e047802b8c0
Content-Type: text/plain; charset=ISO-8859-1

>
> On 10 Nov 2009, at 08:56, Martin Gerdes wrote:
>
> First, how slow is slow? Time from pushing the send button until the new
>> webpage is loaded rises from 10.6 to 103 seconds.
>>
>
> 10.6 is already horrendously slow (unless perhaps it's a 20-year-old PC),
> which leads me to wonder what you're doing. One thing is that with
> ProxyHTMLExtended On you could be parsing lots of text, so make
> sure you use flags to ensure you don't apply more rules to it than
> you absolutely need to.


Its a complex application, its running in a slow VM for testing purposes,
and is itself communicating with a slow test backend in another slow VM. I
am not programming the application, but I have no fear about the 10 seconds.
Especially since they have nothing to do with the proxy: It stays just as
slow if I connect directly to the application (without any encoding
transformations at all). So that simply isn't part of my problem (if it is a
problem, it's someone else's).


>
> Does it make any difference if lots of small rewrites have happened
> vs. if nothing matched any proxy_html rules?
>
> No. It stays just as slow if there isn't a single transformation rule at
all (mod_proxy_html is not doing anything).


> Top on the server shows that the server is sitting idle, so it's not that
>> the recoding is taking up that much CPU (which would be ridiculous anyway).
>>
>
> Does it make any difference if you send an HTTP/1.0 request
> or force a connection close?

The version used in the connections is HTTP/1.1 (I see that in the content
of the transmitted packets).
I wasn't able to try out HTTP/1.0, and haven't looked into how to force a
connection close (what exactly should I try there?)

Instead I have other very interesting observations: I tried the application
out in IE (with the intent to force HTTP/1.0).
Once I press the login button, IE tells me I have no connection to the
internet, and stays with that opinion for any and all sites until I restart
it. Interestingly, IE shows this behaviour even if I comment the line
"ProxyHTMLCharsetOut *" out (which is enough to make firefox fast). [All of
this tried with and without forcing HTTP/1.0]
Commenting out all ProxyHTML directives makes the website work, and work
fast.

Can you get mod_diagnostics
> output to track the data running through the filter?
>
> I'll try that after lunch. Ask if you want to know anything else. (I can
for example packet sniff the connection between IE and the proxy, and give
you the debug output of mod_proxy_html in that constallation. Provided you
are interested in that information.)

Kind regards,

Martin

--000325557352ac1b7e047802b8c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

ss=3D"im">

204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Top on the server shows that the server is sitting idle, so it's not th=
at the recoding is taking up that much CPU (which would be ridiculous anywa=
y).

Does it make any difference if you send an HTTP/1.0 request

or force a connection close?

x solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
=A0Can you get mod_diagnostics

output to track the data running through the filter?

Re: activating xml2enc makes client getting HTML-Page

--00032555a39ac5ed200478046993
Content-Type: text/plain; charset=ISO-8859-1

>
>
> Can you get mod_diagnostics
>> output to track the data running through the filter?
>>
>> I'll try that after lunch. Ask if you want to know anything else. (I can
> for example packet sniff the connection between IE and the proxy, and give
> you the debug output of mod_proxy_html in that constallation. Provided you
> are interested in that information.)
>
>
Okay, I have created a debian package with alien (as there does not seem to
exist a native debian package), and gotten apache to load the module.
Which configuration makes it give it the output you want? (on
http://apache.webthing.com/mod_diagnostics/ I don't see any usage
instructions)

If I still used the old version of proxy-html, I guess I'd change the filter
chain to "SetOutputFilter diagnostics proxy-html diagnostics"?
But that line is commented out now, and replaced by "ProxyHTMLEnable On".
So just tell me how to generate the output you want to have. I'd then send
the output to your email adress only, as there is no need for the
application data to be on the public list.

Martin

--00032555a39ac5ed200478046993
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Re: activating xml2enc makes client getting HTML-Page

--0015175df46ea9702d047806266a
Content-Type: text/plain; charset=ISO-8859-1

A completely different idea to solve my actual problem:

Someone else suggested to just take out the conversions all together.
I mean, I am converting right back into the encoding I converted from. I
have been assured that no link uses a character above the first 128 (7 bit
ASCII). As far as I know there are no HTML control characters outside of 7
bit ASCII either.
So shouldn't the parser just be able to parse the ISO-8859-1 document as if
it was utf-8? Yeah, I know it sounds horrible, but as far as I can tell it
should not actually break...

As author of the module:
Could this work?
What would I have to change in the code to keep any input conversion from
happening?
(I will play around abit myself, but I am not familiar with the code, nor
with Apache module logic. And its been quite a few years since I last coded
C...)

At the very least this would tell us (if it works) whether or not the
conversions are to blame for the problems I experience.

Martin

--0015175df46ea9702d047806266a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

A completely different idea to solve my actual problem:

Someone else=
suggested to just take out the conversions all together.
I mean, I am c=
onverting right back into the encoding I converted from. I have been assure=
d that no link uses a character above the first 128 (7 bit ASCII). As far a=
s I know there are no HTML control characters outside of 7 bit ASCII either=
..

So shouldn't the parser just be able to parse the ISO-8859-1 document a=
s if it was utf-8? Yeah, I know it sounds horrible, but as far as I can tel=
l it should not actually break...

As author of the module:
Could =
this work?

What would I have to change in the code to keep any input conversion from h=
appening?
(I will play around abit myself, but I am not familiar with th=
e code, nor with Apache module logic. And its been quite a few years since =
I last coded C...)


At the very least this would tell us (if it works) whether or not the c=
onversions are to blame for the problems I experience.

Martin
>

--0015175df46ea9702d047806266a--

Re: activating xml2enc makes client getting HTML-Page

--0015175cff0c2fb9580478063d98
Content-Type: text/plain; charset=ISO-8859-1

Alright, just forget I suggested that. If in front of a html character a
byte above 127 appears (a character outside of 7 bit ASCII), the control
character would get interpreted as part of the same character in utf-8. In
other words: It WILL break.
The suggestion just sounded too good. Back to the regularly scheduled
program...

2009/11/10 Martin Gerdes

> A completely different idea to solve my actual problem:
>
> Someone else suggested to just take out the conversions all together.
> I mean, I am converting right back into the encoding I converted from. I
> have been assured that no link uses a character above the first 128 (7 bit
> ASCII). As far as I know there are no HTML control characters outside of 7
> bit ASCII either.
> So shouldn't the parser just be able to parse the ISO-8859-1 document as if
> it was utf-8? Yeah, I know it sounds horrible, but as far as I can tell it
> should not actually break...
>
> As author of the module:
> Could this work?
> What would I have to change in the code to keep any input conversion from
> happening?
> (I will play around abit myself, but I am not familiar with the code, nor
> with Apache module logic. And its been quite a few years since I last coded
> C...)
>
> At the very least this would tell us (if it works) whether or not the
> conversions are to blame for the problems I experience.
>
> Martin
>
>

--0015175cff0c2fb9580478063d98
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Alright, just forget I suggested that. If in front of a html character a by=
te above 127 appears (a character outside of 7 bit ASCII), the control char=
acter would get interpreted as part of the same character in utf-8. In othe=
r words: It WILL break.

The suggestion just sounded too good. Back to the regularly scheduled progr=
am...